This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

Size Change: +403 B (+0.02%)

Total Size: 1.83 MB

_{compressed-size-action}

Flaky tests detected in bc66ed4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9867942148
📝 Reported issues:

• [Flaky Test] Should insert content using the global inserter #57525 in /test/e2e/specs/widgets/editing-widgets.spec.js

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: carolinan <poena@git.wordpress.org>
Co-authored-by: draganescu <andraganescu@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: beafialho <beafialho@git.wordpress.org>
Co-authored-by: henriqueiamarino <iamarinoh@git.wordpress.org>
Co-authored-by: afercia <afercia@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: jameskoster <jameskoster@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Hey @carolinan 👋

Would it be possible to have this be a pattern that consists of a row block with the tag name set to nav instead?

I'm not sure a custom block is the right answer for the valid issue you point out :)

The reason for that is in the linked issue.
The patterns are not surfaced the same way as blocks and are more difficult to find. And having the block would make it consistent with the query pagination.

I would still prefer for this to be a block, but how does one even add a new core pattern? Are they added by issues and PR's to the pattern directory repository?

I would still prefer for this to be a block, but how does one even add a new core pattern?

There are a mixture of ways at the moment. There are some in the block-patterns folder in core:
https://github.com/WordPress/wordpress-develop/tree/trunk/src/wp-includes/block-patterns

They're registered here:
https://github.com/WordPress/wordpress-develop/blob/e3e7fdbf7c3fd9f04871118a16b98f1544e94984/src/wp-includes/block-patterns.php#L18-L37

The majority are registered from the pattern directory, those that are 'featured' or have the 'core' keyword:
https://github.com/WordPress/wordpress-develop/blob/e3e7fdbf7c3fd9f04871118a16b98f1544e94984/src/wp-includes/block-patterns.php#L211-L287

These patterns are only loaded when core-block-patterns support is active.

I'm not sure what the preference is for adding new bundled patterns. This one seems more like a useful utility pattern rather than the more stylistic patterns in the directory, so maybe the first way?

edit: also just to mentioned that if you wanted to experiment with adding the pattern in the gutenberg plugin to start with, it should be possible to add code similar to how those core patterns are loaded in a lib/compat/wordpress-6.7 folder

Adding the nav element to the group does not remove the need for this block.

why can't we just add a nav element to the HTML options for the Group block?

That would help but still:

• many users wouldn't have a clue they should use a <nav> element
• the UI should provide a way to label the <nav> because whe a page has multiple <nav> elements, they need to be distinguished by the means of a label. See https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/navigation.html If a page includes more than one navigation landmark, each should have a unique label.

It is up to the user to choose these elements

I would argue this is not in line with what WordPress always aimed to to. Historically, WordPress always aimed to output valid, semantic, and accessible HTML on the front end. The classic template functions for things like posts navigation etc. take care to output a <nav> element. See for example get_the_posts_navigation, get_the_post_navigation, get_the_comments_navigation and similar functions that, under the hood, use _navigation_markup to generate the HTML and output a labeled <nav> element. There has been previous work to make sure these functions output semantic and accessible navigation. In the same way, the editor should make sure all the navigations rendered on the front end use a labeled <nav> element. This is a responsibility that can't be delegated to users.

Another suggestion is to create variations of the Group block.

wp.blocks.registerBlockVariation( 'core/group', {
	name: 'group-navigation',
	title: 'Post navigation',
	category: 'theme',
	icon: () => {
		return wp.element.createElement(
			wp.primitives.SVG,
			{ xmlns: 'http://www.w3.org/2000/svg', viewBox: '0 0 24 24' },
			wp.element.createElement( wp.primitives.Path, {
				d: 'M21 17.5L21 6L13 6L13 17.5L21 17.5ZM10 14.5L3 14.5L3 16L10 16L10 14.5ZM3 11L10 11L10 12.5L3 12.5L3 11ZM10 7.5L3 7.5L3 9L10 9L10 7.5Z',
			} )
		);
	},
	attributes: {
		metadata: {
			name: 'Post navigation',
		},
		tagName: 'nav',
		ariaLabel: 'Posts',
		layout: {
			type: 'flex',
			justifyContent: 'space-between',
		},
	},
	allowedBlocks: [ 'core/post-navigation-link' ],
	innerBlocks: [
		[ 'core/post-navigation-link', { type: 'previous' } ],
		[ 'core/post-navigation-link' ],
	],
} );

Additionally, provides a UI for editing the ariaLabel attribute (See this comment).

The reason I'm cautious about adding new blocks is that once a block is shipped into core, we need to continue maintaining it in a backwards-compatible manner for as long as the block is available: we can deprecate it, but we can't remove the code. So I'm wondering if there's a way to solve this without adding a new block.

@t-hamano Great thinking. I like the variation approach.

The other thing I wanted to mention, is that we can potentially add some smart detection on how people are using the different tag names and if we can detect mis-use show nudges like we do for color contrast.

I am very surprised by the reluctance to solve this the same way the existing paginations have been solved, I am sensing that this has become about the argument rather than the solution and I don't appreciate it.
There has been no reports of there being any issues with these existing combined blocks that would require changes to those, that would mean turning them into something else like a variation.

This block does absolutely not create a larger maintenance burden than any of the other proposed blocks.

And as far as I know, you can not style those kind of variations site wide. Just like you can't style stack and row separately from the group.
Not with global styles (Styles sidebar) nor a JSON file. And this includes the new section styles and variations in theme.json.

Styling block variations would be good to have, but there is no ETA on resolving it: I don't think that solving known accessibility issues should be blocked by possible future changes, unless that future change is on the immediate roadmap and there is progress.

On the other hand, I wish we had planned for having a single pagination block from the beginning, where the query pagination, comment pagination, next/previous could have been variations or where the pagination type would have been detected automatically depending on the context.

I don't think that solving known accessibility issues should be blocked by possible future changes

To play devil's advocate here, is the ability to style the proposed variation via Global Styles a true blocker for that approach?

Yes because it is a subpar experience compared to editing and styling the other pagination blocks, and creates another inconsistency between them.

There was a comment that this block is only used in templates. Without statistics, we can't know if that is accurate, in the support requests I have received, the user have tried to add it to the post content in the block editor when using Twenty Twenty-Three because that theme does not include this navigation by default.

@WordPress/gutenberg-core How can we move this forward? I see other new blocks getting merged after two weeks without discussion, I still don't think that the arguments against this block are valid.

There is a lot of drift in terms of container block style support. For example I think it’s super weird that you can set background images on some, but not others (like the Pagination block, incidentally). This forces theme devs to utilise inefficient workarounds such as wrapping blocks like Pagination in a Group just to get access to certain style options. The knock-on effect is a more convoluted block tree that is harder for end users to navigate.

The more 'containers' are added, the worse these inconsistencies seem to get.

For that reason I prefer the variation suggestion. It ensures this ‘block’ always matches the Group block in terms of style options, and as already mentioned; reduces the maintenance burden.

I should say that this is all assuming there aren't any styling options that this block needs that are not already present on Group.

The problem is still that

• Using a variation creates yet another inconsistency with the existing pagination blocks.
• Users/developers/designers will not be able to style the pagination separately from group blocks, such as setting a default alignment and spacing around or between the next and previous links, nor style variations of it.
• Having a variation of a group block that is not a container but for a single purpose, this is different from the current group block variations stack, row and grid. This does not make the next and previous navigation easier to use, it makes it more difficult for user to know which group to use when and for what.

I understand that the background image was a single example, but I still feel strongly that not having a background image option is preferable over not being able to add default styles at all.

If you wanted to make a particular style/layout reusable would it not be more appropriate in this case to create a template part or synced pattern? It doesn't seem like a block that will be used very often outside of specific templates?

I have already responded to that multiple times in this discussion, but to add to that:

1. That assumes the user has the knowledge to do that.
2. Synced patterns can not be added by themes and template parts can't be used in the post content/block editor.
3. As you know styles are more portable and flexible when added in theme.json rather than hardcoded as part of the HTML markup. The second also prevents use of style variations since the variations cant override this markup.
4. There are no stats that show how these blocks are used or that it would not be used more if it was easier to add.

That assumes the user has the knowledge to do that.

Since this is a block targeted more towards theme devs that seems like a reasonable assumption?

template parts can't be used in the post content/block editor

Is this a block we expect people to use inside the Content block? It feels more like a template block to me.

These are just my opinions. I don't want to block the effort, but there doesn't seem to be clear consensus either way on this one.

I do understand all the different reasoning on this issue but, to me, the most important point is addressing the underlying usability issue. As mentioned in my previous comment, the current flow to add a fully working post navigation is unnecessarily complex, time consuming, and unintuitive.

I would argue that what users need in most of the cases, whether they are theme authors, devs, or content authors, is to be able to just add a fully working Post navigation with just one click. The block should allow to remove nested blocks if users want to, for example, remove the previous link. Not the other way around.

I disagree with the notion and practice that if a block is used in the Site Editor it is acceptable for that block to be more difficult to use and for it to not be accessible.

That is not how you empower people to create better websites. That is not how you help users learn.
That is how you make people feel like they are not smart enough to do it, it is how you alienate users and push them away.

I would argue that what users need in ost of the cases, whether they are theme authors, devs, or content authors, is to be able to just add a fully working Post navigation with just one click. The block should allow to remove nested blocks if users want to, for example, remove the previous link. Not the other way around.

It looks like @t-hamano's example block variation does that.

I am not going to spend more time on this.

I am expecting to see the following merged:

• A fully accessible next and previous post navigation.
• That does not require multiple steps to set up.
• That can be styled site wide by all: designers, developers, users.
• That can be inserted even if the core block patterns are disabled.

I think the fact that the only way to fully solve accessibility issues is to add a new block means that the editor itself may lack a UI to assist users in creating fully accessible pages.

The Post Navigation Link block isn't the only thing that is expected to be wrapped in a nav element -- for example, a user may insert link buttons or link lists that have navigational implications.

With that in mind, I think the following approach might be effective in the long term:

• Implement an accessibility check button in the editor. When pressed, the entire content or template is parsed, and users are warned about markup or blocks that may not be accessible.
• Show some kind of warning in the block sidebar when the Post Navigation Link block is used alone. For example, "It is recommended that this block be wrapped in a Group block as a nav element."

Either way, I'd love to hear from anyone who has other ideas or approaches to finding the ideal solution.

Adding the nav element to more blocks is already discussed in a separate issue and PR:
#64051
#66866

The nav element is not the only issue that needs to be solved.
The inconsistencies with the other blocks and lack of styling option is not solved by an improved accessibility checker, and everyone so far is dismissing this feedback and the reply to the question that was asked "is the lack of styling really a problem?".

Again, if a theme developer wants to style the query pagination and the next and previous post links the same way, and then design it differently in a style variation, they can't do that.
For example TT5 has a border above the next and previous links that can't be added in any way but using the HTML markup, which again, can't be overridden by a JSON style variation.